Cucumber is a software tool that computer programmers use for testing other software. It runs automated acceptance tests written in a behavior--driven development (BDD) style. Cucumber is written in the Ruby programming language. Cucumber projects are available for other platforms beyond Ruby. Cucumber allows the execution of feature documentation written in business-facing text. Tests are written in plain language based on the BDD style of ‘Given’, ‘When’, ‘Then’, which any layperson can understand. Test cases are then placed into feature files that cover one or more test scenarios. Cucumber interprets the tests into the specified programming language and uses a programming language (e.g., Selenium, Watir, Capybara, Perl, PHP, Python, .Net etc.) to drive the test cases in a browser.
The BDD ‘Given’, ‘When’, ‘Then’ syntax is designed to be intuitive. ‘Given’ provides context for the test scenario about to be executed, such as the point in your application that the test occurs as well as any prerequisite data. ‘When’ specifies the set of actions that triggers the test, such as user or subsystem actions. ‘Then’ specifies the expected result of the test. This BDD syntax is written in feature files which are an essential part of cucumber. A feature gives information about the high level business functionality and the purpose of Application under test. Everybody should be able to understand the intent of feature file by reading the first Feature step. This part is basically kept brief. For example, a feature may he “Login Functionality Feature.” Cucumber also uses the term scenario to describe a particular functionality which is under test. By seeing the scenario, a user may be able to understand the intent behind the scenario and what the test is all about. Each scenario should follow the ‘Given’, ‘When’, ‘Then’ syntax. A scenario may he written in a feature file, as follows:                Feature: Login Functionality Feature        Scenario: Login Functionality        Given user navigates to ABC.COM        When user logs in using Username as “USER”        And password as “password”        Then login should be successful        And Home page should be displayed        
Once a feature file is created, a user may write software code in order to satisfy the scenario being tested. The user may then run the feature file and watch it fail. The user may then write an automation script with the template provided by Cucumber. The behavior of the application may then be satisfied by the test script.
In order to use Cucumber, a user must know how to write the Cucumber feature file. This is a drawback for business users or other non-technical users who do not know how to write the feature file because it makes them dependent on software developers in order to verify the software system being tested. The non-technical users must rely on the software developers to test the tested system for various scenarios, parameter values, etc. Thus, there exists a need for a system that will bridge the gap between business users and Cucumber. This Cucumber dashboard system may let on-technical users create, update and dry run Cucumber test cases for various scenarios, parameter values, etc. That is, the Cucumber dashboard system may let a user perform the following tasks without having any knowledge of Cucumber: create a new feature file, update an existing feature file, and run acceptance test cases with different scenarios and different values.